當團隊開始練習 Specification by Example，往往會遇到一個關鍵問題：「我們該從哪裡著手找範例？」這看似簡單的問題，背後卻藏著需求理解與測試設計的雙重挑戰。許多團隊成員（不論是 PO、RD 或 QA）常常會感到焦慮，擔心漏掉關鍵情境、沒想到邊界案例，或者寫出的例子無法反映出實際的行為差異。

這時，一個源自測試領域的老朋友就派上用場了：Equivalence Class Testing（等價類別分割法，ECT）。

雖然這個技巧常被歸類為黑箱測試設計的方法，主要用來幫助 QA 精簡測試案例、提升測試覆蓋率，但它的價值絕不只如此。它背後的核心觀念──等價類別: 將輸入或條件依照「行為反應相同」的方式分類──其實非常適合拿來作為範例設計的起點。

當我們用 SBE 的方式要釐清規則、找出可驗證的範例時，Equivalence Class Testing (ECT) 提供了一個極具操作性的架構。它不會要你列出所有可能的值，也不是機械式地貼上「有效」與「無效」的標籤，而是引導你去發現：有哪些類型的輸入，系統的行為是一樣的？哪些輸入則會觸發不同的回應？

這種思維能大大降低設計範例時的遺漏風險，也能促進團隊在早期就釐清模糊規則與隱含假設。尤其在複雜邏輯條件（例如：依年齡、會員等級、付款方式決定不同結果）之下，Equivalence Class Testing 可以幫助你聚焦在「行為差異點」上，而不是被無限輸入組合搞得焦頭爛額。

換句話說，等價類測試不只是 QA 的工具，更是 SBE 的助力者。當你學會用這種分類思維去分析需求、設計例子，你就會發現：「找範例」這件事，變得更有邏輯、也更容易對焦在重點。

在接下來的說明中，我們會深入探討 Equivalence Class Testing 的正確觀念、常見誤解、如何設計，以及如何與 SBE 實踐結合起來，讓你的範例更有說服力，也更具備覆蓋效益。

一、等價類別分割法的定義

等價類別分割法（Equivalence Class Testing）其實不是在找「哪個輸入是有效，哪個是無效」，這是很多人誤解它的地方。它的核心其實是：
「針對某個輸入欄位或條件，是否存在一組輸入，它們在系統中會導致相同的結果或流程？」

舉例來說，對於一個「會員等級」的欄位，假設系統的反應如下：
• Bronze、Silver → 顯示「標準運費」
• Gold、Platinum → 顯示「免運費」

那我們其實就可以依照行為，劃分出兩個等價類，而不是單純標記「有效」或「無效」等級。

這種思維最大的好處是：我們在設計範例時，能夠更有策略地去挑出「每種行為」的代表性輸入，而不需要機械地亂試各種值，卻又怕漏掉重要邏輯。

二、如何使用等價類別分割法設計範例集合

步驟一：列出所有可能影響行為的輸入或條件欄位
這不一定只是表單欄位，也可能是：
• 使用者身分屬性（如是否登入、是否會員）
• 操作背景（如是否在活動期間）
• 外部狀態（如存貨是否足夠）

步驟二：針對每一個欄位或條件，詢問「有哪些行為分岔？」
這是關鍵步驟，要跳脫傳統「有效/無效」框架，改問：
• 這個欄位的不同值，會不會導致不同回應？
• 哪些值會被系統「當作一樣處理」？
• 哪些值會被視為「特殊例外」？

步驟三：根據行為結果將輸入分類成不同等價類
每一個等價類都對應到一種具體行為，例如：
• 計算方式
• 顯示內容
• 是否允許下一步動作
• 錯誤訊息類型

步驟四：從每個等價類中選出具有代表性的值
通常可以選 1～2 個，尤其是臨界值、常見輸入、或容易被誤解的輸入。

三、注意事項

(1) 不要過度簡化為「有效 vs 無效」兩類
說明：很多人以為等價類別測試就是把輸入分成「合法」與「不合法」，這會導致範例落在「格式對／格式錯」這類表面問題，而忽略了不同輸入對行為的影響。

案例：高鐵校外教學票價規則中，「學歷」這個欄位：
• 小學生（4 折）
• 國中、高中、大專以上（7 折）

若你只分「合法學歷／不合法學歷」，會忽略這兩個群體對折扣行為的實際差異，進而錯失需要釐清的核心規則。
小技巧：觀察「行為上是否有差異」，才應視為不同等價類別。

(2) 等價類別不是來切輸入欄位，而是切「行為意圖」
說明：SBE 目的是理解與釐清需求，因此重點是哪些輸入被系統視為「一樣的處理方式」，而非只是不同的資料格式或數值區間。

案例：高鐵團體人數規則
• 11–24 人：可買團體票
• 25 人以上：有額外折扣

這裡不是在檢查「人數是大於 0 嗎」，而是：不同人數區間是否導致「不同的處理或優惠」
建議：不要只是「找資料異同」，而是問「系統會對這群人做什麼？」

(3) 建立等價類別前，要先問：這個欄位會影響行為嗎？
說明：不是每個輸入欄位都需要建立等價類別。如果這個欄位根本不影響行為，那就不需要在 SBE 中特別建立範例釐清。

案例：高鐵訂票系統的「旅客手機號碼」欄位
這是必要欄位，但對「是否符合優惠」並無影響。若你試圖對這欄位做等價分類（例如 10 碼／11 碼／錯誤格式），會偏離需求釐清的焦點。

建議：每次要分類前，先問「這個影響系統行為嗎？」

(4) 不要只看單一欄位，要觀察「多欄位交錯下的等價關係」
說明：很多優惠條件是多欄位組合而來，單一欄位的等價分類在多欄位情境中會破功。
案例：在高鐵優惠中：
• 「學校團體」+「指定車次」+「對號座」+「小學生」→ 4 折
• 「非學校團體」+「同樣條件」→ 無優惠

若你單看「小學生」這一欄，就以為所有小學生都適用 4 折，會誤導出錯的範例。

小技巧：透過等價類別先找基礎條件，再觀察是否需要 Decision Table 輔助交錯分類。

(5) 別忽略「邊界類別」的重要性，這些通常最容易觸發錯誤解讀
說明：即使 SBE 不強調測試邊界，但從需求釐清角度來看，「臨界點」常是 PO 或 BA 忽略的地方，會導致規則空缺或矛盾。

案例：人數滿 11 人才有團體票權益，那：
• 10 人：不能買？
• 11 人剛好就可以？
• 10 人＋嬰兒算不算？

建議：等價類別測試的強項之一是識別「邊界值的例外」，這在 SBE 中應至少選一兩個代表例納入討論。

四、結合 Specification by Example 的範例

當我們把等價類別思維帶入 SBE 的範例設計過程中，整個設計過程會變得更有方向感。以下用一個實際例子說明。

例子ㄧ：線上投保系統的年齡輸入邏輯
假設系統有如下規則：
• 0–17 歲 → 不可投保，顯示「未成年」
• 18–65 歲 → 標準費率
• 66–75 歲 → 高齡費率 +20%
• 76 歲以上 → 拒保，顯示「超過年齡限制」
• 非數字或空值 → 顯示「輸入錯誤」

需要考慮的變數以及相關的等價類別分割如下：

1. 年齡
   0–17：拒保 + 未成年訊息
   18–65：計算標準費率
   66–75：計算費率 + 加成
   ≥76：拒保 + 超齡訊息

2. 非數字輸入：錯誤訊息

3. 空白欄位：錯誤訊息

對應範例表如下：

這樣的範例集合，不但明確反映每一種行為分岔，也能幫助 PO 與開發團隊在需求釐清階段看清楚所有例外與邊界處理，進而防止遺漏邏輯。

例子二：高鐵校外教學優惠

接下來我在來看個高鐵的案例，這裡是高鐵團隊要處理「學校校外教學」線上訂票功能，我們來看看等價類別思維如何幫助SBE 討論的場景。

(a) 場景：高鐵產品開發會議室，週二上午
PO 小美正在簡報：「根據新政策，台灣的國小、國中、高中、大專院校帶學生出遊時，如果人數滿 11 人、搭乘指定車次、對號座，就可以申請『校外教學優惠』。小學生 4 折，國中以上學生 7 折。」

她接著補充：「如果不是學校，只是一般團體，像公司旅遊，只要滿 25 人，也能在指定車次享有平日 7 折、假日 8 折。」

工程師阿明聽了點點頭：「所以系統邏輯應該不難吧？就是學生 vs 非學生、學校 vs 非學校、11 人 or 25 人以上這種條件判斷。」

QA 小貞沒說話，只是默默記下關鍵詞：「指定車次、對號座、人數門檻、學歷、日期……」
過了幾秒，她開口了：「我們可不可以來試著舉幾個例子？我擔心條件有重疊的時候，會搞混優惠怎麼判斷。」

(b) 來回釐清的第一回合
阿明舉了個例子：「學校帶 20 位國中生出遊，應該就 7 折吧？」

小貞問：「是哪天？」
「假日。」
「搭什麼車次？」
「嗯……應該是最早那班？我不確定是不是指定車次。」

小貞笑了：「如果不是指定車次，那就不適用校外教學優惠，變成一般團體票。」

阿明愣住：「欸？我以為只要是學校就有。」

PO 嘆口氣：「我們現在知道一堆條件，但沒辦法說清楚什麼情況該套用哪種優惠。」

(c) 恍然大悟時刻：等價類測試上場了！
這時，小貞站起來說：「我們現在就是在亂猜，因為我們還沒釐清每種輸入值會造成的行為差異。」

她走到白板前，一邊畫一邊說：
「在測試裡，有一個常用的技巧，叫做 Equivalence Class Testing（等價類測試）。
它的核心概念是：只要一群輸入值會導致相同的系統行為，就可以歸成一個類別。
我們不需要列出所有組合，只要挑出每個等價類的一個代表例子，就能全面涵蓋。」

工程師們面面相覷，PO 驚訝地問：「這是測試人在用的嗎？我們也可以用來設計範例？」

小貞點頭：「沒錯，Specification by Example 強調用具體範例釐清需求，而 Equivalence Class Testing 就是幫助我們找對、有代表性的範例。」

(d) 分類與反覆澄清的第二回合：從亂猜到有依據
她在白板上列出分類：

然後寫出行為差異：
• 校外教學優惠 → 小學 4 折 / 國中以上 7 折
• 非學校 25 人以上團體 → 平日 7 折 / 假日 8 折
• 一般團體票 → 沒有折扣（但可預訂）

這時 PM 又問：「那混合年齡怎麼算？小學＋高中？」

阿明跟著補：「老師算不算人數？車廂是自由座還是對號座有差嗎？」

小貞冷靜地說：「這些都是我們今天要釐清的模糊點，我們先聚焦『有明確行為差異』的條件，後續模糊的，我們再請 PO 做確認。」

(e) 建立等價類與代表性範例
小貞開始帶大家寫出等價類與對應範例：

接著每個等價類都挑出一組範例進行討論，並用 Gherkin 或表格呈現，逐步形成 Specification by Example 範例集。

(f) 模糊點暫緩處理，但標記下來
正當大家忙著記錄時，PM 又問了一次剛剛的問題：
「所以混齡團體到底怎麼算？我們 UI 要不要分開輸入？還是全部視為最高年級？」

小貞沒有直接回答，而是溫和地說：
「這個我建議先標記為『待釐清』。目前高鐵政策文件沒寫，我們沒辦法自己定義系統行為，這應該讓 PO 去問營運單位。」

她寫下：
特殊情境（待釐清）

阿明點頭：「對，我一開始以為我們應該一次把邏輯講清楚，但其實這樣分開處理才務實，避免糾結一個點卡整場會。」
PO 小美邊做筆記邊說：「好，我會把這些模糊點一併整理出來，週五去和高鐵窗口確認。」

(g) 老師是否算入人數？也留待確認，但不打亂進度
此時另一位 RD 補了一句：「那老師算不算人數呢？會不會『10 位學生 + 1 位老師』就剛好過門檻？」

小貞再度平靜地說：「這也屬於不確定的行為判定，建議一樣列成待釐清。」

她補充說：「但我們不會現在去決定它，而是確保這些模糊點在需求確認清單中有一席之地。」

(h) 小結：範例設計的進展不是靠猜，而是靠策略分類與釐清
白板上的分類與範例越來越清楚，會議也進入尾聲。PO 小美回顧整場討論後說：

「我們今天先釐清了 5 個主要等價類，建立了每個行為對應的範例，同時發現了 2 個未定義但重要的例外情境。這樣的節奏很好，讓我知道該回去問什麼，而不是回去寫一份全是空泛邏輯的 BRD。」

小貞微笑著說：

「Specification by Example 的重點不是一次講清楚所有事，而是透過例子建立共同理解，再用分類引導需求釐清的節奏。Equivalence Class Testing 幫我們決定要先講哪一類，哪些例外可以後補。」

會議在一種安定、有共識的氛圍中結束。他們知道自己離完整的需求還有距離，但也知道——自己正走在一條比過去更清晰的路上。

(f) 會議尾聲：從技術轉化成共同語言的瞬間
當最後一組範例寫完，PO 小美看著白板上條列的分類與範例，長嘆一口氣後笑了出來：
「我原本以為我們是在寫測試案例，結果你讓我們釐清了整個業務規則。」

PM補了一句：「這個 Equivalence Class Testing 根本是分析工具，不只是測試技巧。」

阿明舉手說：「下次我寫邏輯分支前，請先讓 QA 開個等價類清單給我！」

所有人都笑了。

那天，他們沒寫一行程式碼，但建立了範例設計的共識、找出需求漏洞，也讓「等價類別」成為了團隊討論行為差異的共同語言。